home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 001129_grobe@ukanaix.cc.ukans.edu _Fri May 14 20:53:27 1993.msg < prev    next >
Internet Message Format  |  1994-01-24  |  3KB
  1. Return-Path: <grobe@ukanaix.cc.ukans.edu>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA19726; Fri, 14 May 93 20:53:27 MET DST
  4. Received: from ukanaix.cc.ukans.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  5.     id AA10383; Fri, 14 May 1993 21:14:26 +0200
  6. Received: by ukanaix.cc.ukans.edu (AIX 3.2/UCB 5.64/4.03)
  7.           id AA28557; Fri, 14 May 1993 14:16:04 -0500
  8. From: grobe@ukanaix.cc.ukans.edu (Michael Grobe)
  9. Message-Id: <9305141916.AA28557@ukanaix.cc.ukans.edu>
  10. Subject: Re: Formatting Options in HTML?
  11. To: www-talk@nxoc01.cern.ch
  12. Date: Fri, 14 May 93 14:15:58 CDT
  13. X-Mailer: ELM [version 2.3 PL2]
  14.  
  15.  
  16. in regard to the question of supporting centering and right justification
  17. and compact in html (and with apologies to anyone who gets
  18. redundant copies):
  19.  
  20. i am a new user of html, and an old user of roff.  my first reaction
  21. to html was "what a weak formatting language."  as i thought more
  22. about displaying documents on a wide variety of clients, however, i
  23. began to understand better what markup without formatting was about
  24. and thought "what a clever idea to let clients use whatever capabilities
  25. they have to display what needs to be displayed."  as i prepared
  26. my first document (which is a quick reference to html by the way), i
  27. was frequently frustrated by not being able to get things to look
  28. quite right.  in particular, <dl> didn't seem to want to cooperate
  29. with my aesthetic (nor did <dl compact>.)  finally, i realized that
  30. it was the renderer, not html, that was not cooperating; html provided
  31. a suitably defined <dl> structure, but the renderer was making 
  32. decisions i didn't like.
  33.  
  34. extrapolating just a bit from this line of experience, i concluded that
  35. an html renderer (or www client) should allow the READER to
  36. define how to render html constructs.  for example, the reader should
  37. be able to define the typeface, indentation, line spacing, and characters
  38. used for bullets (if any) at each level of a nested <ul>. in addition,
  39. the reader should be able to change this rendering while viewing a particular
  40. page.  in this context, the centering and right justification questions
  41. seem to become a matter of reader choice. the reader may choose to have
  42. the client center headers and right justify text, or not.
  43.  
  44. having prepared documents for years, i have spent a lot of
  45. time trying to pick display formats that convey information clearly.
  46. it is something of a relief to imagine moving the display format
  47. responsibility away from the information provider to the information 
  48. consumer (not the client program, but the reader herself), who should
  49. actually be able to do a better job of it, since each reader knows
  50. or can discover her own preferences (provided, of course, that the
  51. client gives them the capability). 
  52.  
  53. from this perspective the "compact" of <dl compact> is even something
  54. of an encroachment into the responsibilities of the renderer/reader.
  55.  
  56. as i mentioned, i am new to html, so this may be old hat to the www
  57. community, but it may also serve to remind veteran users of the
  58. learning process experienced by new users.
  59.  
  60. :michael grobe
  61. academic computing services
  62. the university of kansas
  63.  
  64.  
  65.